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Trajectory-based operations (TBO) is a key concept in the Next Generation Air 
Transportation System transformation of the National Airspace System (NAS) that will 
increase the predictability and stability of traffic flows, support a common operational picture 
through the use of digital data sharing, facilitate more effective collaborative decision making 
between airspace users and air navigation service providers, and enable increased levels of 
integrated automation across the NAS. NASA has been developing trajectory-based systems 
to improve the efficiency of the NAS during specific phases of flight and is now also exploring 
Advanced 4-Dimensional Trajectory (4DT) operational concepts that will integrate these 
technologies and incorporate new technology where needed to create both automation and 
procedures to support gate-to-gate TBO. A TBO Prototype simulation toolkit has been 
developed that demonstrates initial functionality of an Advanced 4DT TBO concept. Pilot and 
controller subject matter experts (SMEs) were brought to the Air Traffic Operations 
Laboratory at NASA Langley Research Center for discussions on an Advanced 4DT 
operational concept and were provided an interactive demonstration of the TBO Prototype 
using four example scenarios. The SMEs provided feedback on potential operational, 
technological, and procedural opportunities and concerns. This paper describes an Advanced 
4DT operational concept, the TBO Prototype, the demonstration scenarios and methods used, 
and the feedback obtained from the pilot and controller SMEs in this focus group activity. 


I. Introduction 


Over the next 20 years, domestic revenue passenger miles are projected to increase 2.1% per year while 
international revenue passenger miles are forecast to increase 3.5% per year'. Furthermore, explosive growth in 
unmanned aerial systems in the National Airspace System (NAS) and increases in general aviation brought about by 
on-demand mobility are foreseen to push the overall traffic demand far beyond the original Joint Planning and 
Development Office (JPDO) predictions for 2025. New aircraft types utilizing the airspace not only create a capacity 
concern in the NAS but will also create a large disparity in vehicle performance and equipage. New environmentally- 
friendly and clean-energy vehicles may require significantly different flight profiles to realize their environmental 
benefits. There is a growing environmental need for legacy aircraft to fly low-noise, fuel-efficient flight profiles to 
reduce airport noise and emissions in all weather and traffic conditions. Access to space and future supersonic 
transports must also be accommodated. This disparity, coupled with inconsistent use of ground automation, often 
leads to inefficiencies in the NAS during both nominal and off-nominal (e.g., disruptive weather or unusually high 
traffic) operations, creating unnecessary delays that result in lost revenue for aircraft operators, lost time for 
passengers, and adverse environmental impacts. 

NASA has developed trajectory-based systems to improve the efficiency of the NAS. Many of these systems are 
targeted at a specific phase of flight, such as departures, cruise, or arrivals. An Advanced 4-Dimensional Trajectory 
(4DT) concept will integrate these technologies and incorporate new technology where needed to create both 
automation and procedures to support gate-to-gate trajectory-based operations (TBO). The primary objective of 
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Advanced 4DT is to accelerate the implementation of a trajectory-based system that both aligns with, and extends 
upon, the Federal Aviation Administration’s (FAA’s) Next Generation Air Transportation System (NextGen) vision. 
The proposed Advanced 4DT system will improve the efficiency of the NAS, reduce fuel and noise emissions, and 
reduce system delay while maintaining or improving the current level of safety by enabling strategic planning, flexible 
user preferred re-routing, electronic trajectory negotiation, and trajectory synchronization among all relevant systems 
and stakeholders. 

NASA has developed an Advanced TBO Prototype simulation toolkit that demonstrates initial functionality that 
may exist as part of an Advanced 4DT TBO concept. The objectives of the Prototype were to develop an initial TBO 
simulation capability leveraging existing tools where possible and prototypes as needed; develop an initial set of 
requirements for ground and airborne systems for performing TBO operations; and engage stakeholders and subject 
matter experts (SMEs) as part of a focus group evaluation. The SMEs participated in discussions of an Advanced 
4DT operational concept and were provided an interactive demonstration of the TBO Prototype using four example 
scenarios. This paper describes an initial Advanced 4DT operational concept, the TBO Prototype, test method, and 
the feedback obtained during the focus group evaluation. 


II. Advanced 4DT TBO Concept 


In current day operations, air traffic controllers manage separation between aircraft using tactical speed, heading, 
and altitude commands transmitted to the aircraft via voice communication. The controller who is issuing these 
commands often does not have a full picture of the impact of those commands on downstream flows and constraints. 
When large perturbations, such as convective weather, force aircraft to be re-routed, traffic managers and controllers 
revert to pre-planned playbooks which may not be optimal for a given situation. Additionally, current decision support 
tools designed to help controllers and traffic managers meter aircraft cannot be used once aircraft are vectored off of 
a known route. There is a need for new air traffic management automation that is robust to large perturbations such 
as convective weather, enables fuel efficient and flexible user-preferred re-routes (UPRRs), and enables strategic 
planning. A key concept in the NextGen transformation of the NAS, which was designed to address these problems, 
is the implementation of gate-to-gate TBO??“. 

TBO utilizes 4DTs that span all phases of flight, from pushback to arrival at the gate, as the basis for planning and 
executing all flight operations. The mode of operations and the requirements of the airspace dictate the specificity of 
the trajectory. As the flight progresses, more detail is added to the downstream trajectory as needed for flow 
management, resource allocation, and separation assurance. Trajectories are negotiated between the operator and the 
Air Navigation Service Provider (ANSP), both preflight and during the flight, as conditions change, to satisfy the 
operators’ business objectives and preferences while meeting ANSP constraints. User preferences are accommodated 
to the greatest extent possible, and trajectories are constrained only to the extent required to maximize capacity and 
accommodate demand, or for other concerns, such as safety, security, or the environment. In high-density or high- 
complexity airspace, the ANSP may need to limit the aircraft to a given published airway and assign constraints at 
specific points; while in low- to medium-density airspace, a wind-optimal route defined by a series of arbitrary points 
in space identified by latitude and longitude might be negotiated. The use of precise 4DTs dramatically reduces 
trajectory uncertainty and enables the airspace to be used more effectively to safely accommodate high levels of 
demand, reduce environmental impacts, and maximize the use of capacity-limited airspace and airport resources. 
Furthermore, TBO will increase the predictability and stability of traffic flows, support a common operational picture 
through trajectory synchronization, facilitate more effective collaborative decision making between airspace users and 
the ANSP through electronic trajectory negotiation, and enable increased levels of integrated automation across the 
NAS. 

TBO is a significant paradigm shift in the way flights are managed. Consequently, the transition to TBO will 
occur gradually over time as flight deck and ground-based automation is developed and as supporting infrastructure 
is deployed. An evolutionary path from today’s air traffic system to a future TBO system must be clearly defined. 

The FAA is committed to moving toward TBO and is making significant progress in working with 
EUROCONTROL to define and implement globally harmonized standards for key infrastructure to support the 
transition to TBO, such as Automatic Dependent Surveillance — Broadcast (ADS-B), digital Data Communications 
(DataComm), and System-Wide Information Management. Near- and mid-term NextGen Collaborative Air Traffic 
Management and traffic management tools, for use by either the ANSP or the airline dispatchers, as well as flight 
deck-based technologies, are already moving towards some of the capabilities and benefits that full TBO is expected 
to provide. The FAA is developing a concept of operations for TBO and has conducted a simulation demonstration 
of 4DT operations that included Dynamic Required Navigation Performance (DRNP) and Advanced Interval 
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Management (A-IM). DRNP is a concept for re-routing aircraft by the ANSP by up-linking a fully-specified 3- 
dimensional path clearance along with the Required Navigation Performance (RNP) values necessary to allow for 
conformance monitoring onboard the aircraft. A-IM is an extension of Interval Management (IM) for pair-wise 
spacing that can be used in conjunction with other operations, such as along DRNP routes. NASA’s Advanced 4DT 
concept focuses on combining these same capabilities with fewer restrictions. 

The Advanced 4DT concept provides the traffic manager and/or the controller with a capability for identifying 
aircraft that will be impacted by convective weather or other system constraints and developing dynamic re-route 
resolutions. Proposed re-routes are sent to the radar controller for consideration and issuance to aircraft. These re- 
routes are designed to be free from weather conflicts for a prescribed period of time. The re-routes can also be 
constrained to a limited number of off-route named fixes or be a series of latitude, longitude points, and can be 
augmented by RNP values where necessary. The former can be communicated via voice clearance while the later 
requires the receiving aircraft to be equipped with Controller-Pilot Data Link Communications (CPDLC). These re- 
routes are also supplied to a scheduling system, such as Time-Based Flow Management (TBFM), in a way that 
supports metering aircraft to any point in space, or along ad-hoc routes. 

Aircraft equipped with route optimization tools have the ability to initiate trajectory negotiations from the flight 
deck>. The aircraft are able to develop user-optimized trajectory changes and send those to the ground automation as 
a re-route request. These re-routes may include latitude and longitude defined points and the trajectory negotiation 
process is conducted via data rather than voice communications. This negotiation process may require the input of 
the Airline Operations Center (AOC) depending on the magnitude of the route change. 

For sufficiently equipped aircraft, data communications are also used to share trajectory information from the 
aircraft to the ground automation platforms using the Extended Projected Profile (EPP) message. The EPP may be 
used within several air traffic management and control functions, including conflict detection, trajectory 
synchronization, and estimated time-of-arrival (ETA) derivation. It is expected that the ETA from the aircraft will be 
a better representation of the aircraft’s capabilities than an ETA calculated by the ground automation. 

The Advanced 4DT concept will support improvements in execution of metering, merging, and spacing functions. 
The ground automation can use the ETAs from the 4DT at key points to support metering. Once aircraft are within 
the freeze horizon of a metering scheduler, the controller has available the options to provide speed advisories to the 
aircraft to meet the Scheduled Time-of-Arrival (STA); to issue a Required Time-of-Arrival (RTA) where the aircraft 
will use their Flight Management System (FMS) to manage their speed to meet their STA; or to issue an A-IM 
clearance where the aircraft manages their speed to achieve and maintain a spacing relative to their leading aircraft 
that matches the spacing needed at the meter fix. The controller’s decision support tools will recommend the 
appropriate action including preparing CPDLC messages to be sent to appropriately-equipped aircraft. 

The Advanced 4DT concept is seen as a stepping stone towards full gate-to-gate TBO. 


III. TBO Prototype 


A TBO Prototype capability was developed to allow for demonstrations of some of the functionality of an 
Advanced 4DT concept. This Prototype development targeted the following set of objectives: 

° develop an initial set of requirements for ground and airborne systems for performing TBO operations; 

. develop an initial TBO simulation capability leveraging existing tools where possible and rapid prototypes 

as needed; 

. demonstrate specific concept elements to stakeholders and subject matter experts to obtain feedback on the 

concept; and 

. identify gaps in the existing tools and simulation capabilities. 

The Prototype was targeted at demonstrating functionality that could be available in a mid-term time frame (2025- 
2035). In that regard, the Prototype had the ability to simulate both legacy aircraft equipage as well as more advanced 
TBO equipage, which includes DataComm and the sharing of 4DT information via Automatic Dependent Surveillance 
- Contract (ADS-C) reports. 


A. Prototype Architecture 

The TBO Prototype integrated three existing simulation systems with a newly-developed simulation capability. 
The Airspace and Traffic Operations Simulation (ATOS)® is a simulation capability that includes a high-fidelity 
aircraft simulation, known as the Aircraft Simulation for Traffic Operations Research (ASTOR), which emulates the 
functions of a modern commercial airliner. The ASTOR capabilities include: a Research Prototype Flight 
Management System (RPFMS), DataComm, multiple-RTA capability, and more. The ASTOR’s capabilities were 
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augmented for the TBO Prototype work. The Traffic Aware Planner (TAP) is a route optimization tool that continually 
searches for route changes that produce time or fuel savings relative to an aircraft’s current route. This capability was 
used in conjunction with the ATOS simulator to generate UPRR requests. The Multi-Aircraft Control System (MACS) 
is a software package that emulates much of today’s air traffic control functionality. MACS can be used with the TBO 
Prototype to display the position of simulated aircraft on an air traffic controller’s scope; however, it should be noted 
that MACS was not enabled for this focus group evaluation. Finally, the Trajectory-Based Operations Toolkit for 
Integrated Ground and Air Research, or TBO-TIGAR, was a newly developed simulation capability that supported 
both simulation of lower fidelity aircraft as well as prototype implementations of various TBO capabilities or 
functions; these included: CPDLC, ADS-C, DRNP re-route generation, and more. The TBO-TIGAR and ATOS 
simulations used a communications interface that leveraged an open-source Data Distribution Service (DDS) protocol. 
Figure | shows an architectural and functional diagram of the TBO Prototype. The following sections describe each 
of the TBO Prototype capabilities and functions developed for this activity in more detail. 
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Figure 1. TBO Prototype architecture and functionality description. 


B. Prototype Capabilities 


Dynamic Area Navigation/Required Navigation Performance 

The TBO Prototype included the ability to dynamically generate re-routes in the form of Dynamic Area Navigation 
(DRNAV) routes. DRNAVs are dynamically-generated area navigation (RNAV) re-routes - navigating by means of 
named fixes and navigational aids - but do not specify any navigational performance requirement. The DRNAV 
functionality allowed for the on-demand drawing of these re-routes and assigning those as clearances to candidate 
flights via voice or DataComm. The capability allowed for DRNAV re-routes where the initial and final re-route 
waypoints were ona flight’s active flight plan as well as the ability to connect an existing flight plan to a DRNAV re- 
route in space, where the initial and final re-route waypoints were not part of the active flight plan. Appropriate re- 
route clearances were automatically generated by the DRNAV capability. 
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The TBO Prototype also included the ability to automatically generate DRNP re-routes. DRNPs are based on the 
similarly-named concept of operations by the FAA’ and are targeted at improving the flexibility of the NAS. A 
DRNP?*» is a re-route defined by a set of waypoints (which can include latitude/longitude points), RNP data for the 
re-route on a leg-by-leg basis, and fixed-radius-transitions or radius-to-fix legs to fully define the turn geometries 
along the re-route. The DRNP capability implemented in the TBO Prototype provided the ability to automatically 
generate a DRNP re-route that was clear of weather given the following information: starting waypoint, ending 
waypoint, re-route activation time, re-route duration, and an average groundspeed for the re-route. The capability 
computed a DRNP re-route that satisfied these input parameters and avoided a set of weather cells, taking into account 
each cell’s expected movement with time. This prototype capability also provided information about the flights in the 
simulation that were candidates for the DRNP re-route solution by evaluating each’s flight’s geometric and temporal 
feasibility in reaching and executing a potential re-route clearance for the DNRP re-route solution. DNRP re-route 
solutions included latitude and longitude defined waypoints. Appropriate re-route clearances were automatically 
generated as needed and could be sent to data link equipped flights. Flights that received DRNP re-routes through 
DataComm were assumed to have the ability to automatically load the re-route clearance into the Flight Management 
System (FMS). 


ADS-C and Extended Projected Profile 

The sharing of trajectory information between an aircraft and ground automation was accomplished via a 4DT in 
the form of an EPP, as defined in RTCA DO-350A® and RTCA DO-351A°. The EPP consists of up to 128 trajectory 
points, each containing a set of required and optional fields. The EPP data is one element of a report message that is 
generated based on an ADS-C contract. The prototype ADS-C implementation allowed for trajectory sharing of EPP 
information on a periodic basis for aircraft equipped with an FMS and DataComm. The EPP trajectory shared by 
equipped aircraft was used in four functions by the TBO Prototype: available for graphical display by the ground 
automation; to update flight plan information in ground automation; for advanced interval management clearances; 
and to derive ETAs in time-based metering schedulers. 


Advanced Interval Management 

The TBO Prototype included an implementation of an A-IM capability. A-IM is a future flight deck concept that 
will enable an aircraft to either achieve or maintain a precise spacing interval behind another aircraft!° for merging 
and spacing operations. A-IM builds on the initial version of IM that is currently being transitioned to industry 
stakeholders by adding the ability to use the 4DT information for the target aircraft, when available, in a DataComm 
clearance. A-IM will also increase the types of IM operations that can be conducted. 

The prototype A-IM functionality in the TBO-TIGAR ground automation enabled a controller to automatically 
generate an A-IM clearance through a set of simple inputs: IM aircraft; target aircraft; achieve-by-point (ABP), 
termination point; and spacing interval. Given these inputs, the ground automation in TBO-TIGAR composed the 
appropriate data link clearance for controller review and issuance to the IM aircraft. These clearances contained the 
4DT information for the target aircraft obtained from that aircraft’s last shared EPP. The inherent assumptions under 
this prototype A-IM implementation were that: both the target aircraft and the IM aircraft had DataComm; the target 
aircraft was under an ADS-C contract to provide EPP information; the aircraft receiving the clearance had an IM 
capability; and that the EPP information for the target aircraft was sent only once (with the clearance) to the IM 
aircraft. 

A prototype A-IM capability and algorithm was implemented for the TBO-TIGAR simulated aircraft. This 
capability allowed these aircraft to receive and parse the A-IM clearance through a data link message and to manage 
the pair-wise spacing to an ABP. This initial implementation only allowed for precise spacing clearances to the ABP, 
where the aircraft was expected to reach the required spacing at or before the ABP and the operation terminated when 
the ABP was reached. The prototype IM algorithm computed an ETA for the target aircraft by using that aircraft’s 
4DT, applied an along-track correction to that 4DT to account for staleness of the 4D information, and computed an 
RTA for the IM aircraft at the ABP by adding the required spacing to this adjusted ETA. An RTA tolerance of 5 
seconds was used by the IM algorithm to manage the spacing error. 


Required Time-of-Arrival 
An RTA capability in the TBO prototype allowed RTAs to be issued to specified flights via DataComm. An RTA 
capability was already available in the ASTOR’s RPFMS and was leveraged without modification. A simple, 
prototype RTA functionality was developed for the TBO-TIGAR simulated aircraft targeted for use in the en route 
phase of flight. The simple algorithm allowed for up to a 10 percent change in cruise speed in the flight plan legs 
leading up to the RTA waypoint, with most of the time adjustment being done close to the RTA waypoint. For RTAs 
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generated by a time-based metering scheduler, data link clearances with RTA constraints were automatically 
composed and presented to controllers for issuance to a flight. 


User-Preferred Re-Route Requests 

The TBO Prototype included the ability for the flight crew to send a request for a UPRR to ground automation via 
DataComm. This prototype capability used a combination of the ASTOR simulation and the TAP tool. The TAP tool 
provided the flight crew with route change advisories (lateral, vertical, or lateral and vertical) that were optimized for 
time or fuel savings, given the active route and weather or other constraints. These route change advisories could be 
entered by the flight crew into the FMS as a route modification and shared with ground automation, thereby 
establishing a UPRR request between the flight deck and the ground automation. The UPRR request was transmitted 
in the form of a 4DT, leveraging the same format as an EPP trajectory. UPRR requests were received by ground 
automation and were available to the air traffic controller in graphical form as lateral and vertical flight profiles. 


Time-Based Metering and Scheduling 

A simple time-based metering and scheduling capability was prototyped in the TBO-TIGAR simulation. The 
time-based scheduler could be configured to manage the traffic to one or multiple destinations and pass through one 
or multiple meter points. The scheduler managed the traffic flow through the set of meter points by computing 
appropriate STAs for each flight based on that each flight’s ETA and the required spacing interval. The scheduler 
used a horizon 30 minutes prior to the meter points where each aircraft’s STA would be frozen. Each flight was 
assigned an STA equal to or at some time later than that flight’s ETA. The ETAs within the scheduler were computed 
using either a simple trajectory prediction based on the flight plan information, or the shared EPP information if that 
data was available. Although simple in its implementation, the prototype scheduling algorithm mimicked some of the 
functionality available in the FAA’s TBFM tool. 


Communications 

The TBO Prototype emulated the major components of a DataComm environment. CPDLC allowed for the ground 
automation to send clearance messages to flights and for flights to provide an appropriate response to ground 
automation. Vehicle state information was broadcast by each flight via a true state message (no ADS-B error) and 
was received by ground automation and flights with assumed ADS-B-In capabilities. The Aeronautical 
Telecommunication Network, Baseline 2, DataComm standards®? were used to create an emulation of the ADS-C 
capability to enable the broadcast of EPP trajectory information from equipped aircraft to the ground automation. 

Voice clearances were implemented using simulation messages — similar to the data link equipped aircraft — 
because all aircraft were simulated and did not have live flight crews. The exception was the single ASTOR aircraft, 
which did have live pilot support but that aircraft was data link equipped and did not require voice clearances. All 
communications (CPDLC, ADS-C, and state information) between the ASTOR aircraft and the TBO-TIGAR ground 
automation used the DDS communication interface. 


IV. System Description 


The Advanced 4DT TBO Prototype system implementation was comprised of ground-based systems, airborne 
systems, and the communication systems between them. The prototype system was configured in the laboratory 
environment with a single aircraft workstation and a single ground-based workstation as seen in Figure 2. The aircraft 
workstation included the ASTOR simulated aircraft and the TAP route optimization application. The ground-based 
workstation included the TBO-TIGAR prototype tool with the various functions described in Section HI. In this 
section, the various interfaces implemented to exercise the prototype functionality will be described. 


A. Ground Automation 

The TBO-TIGAR prototype ground automation system included the tools necessary to: simulate a set of aircraft; 
assess the state of the simulation; generate and issue clearance instructions; and generate trajectory path and time 
constraints. This suite of tools can be respectively categorized in three components: a flight manager, air traffic control 
automation, and flow management tools. Each of these components will be described in the following sections. It 
should be noted that the goal of this 4DT Prototype was not to define user interface requirements or design specific 
interfaces for ground automation tools but, rather, to demonstrate the prototype functionality. As such, the interfaces 
to the ground automation tools were simple engineering views into each of the simulation components. 
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Figure 2. Advanced 4DT Prototype system in the laboratory environment. ASTOR simulation and TAP 
application (top) and TBO-TIGAR ground automation tools (bottom). 


Flight Manager 

The flight manager was a low- to medium-fidelity flight simulator that generated flight trajectories for a set of 
flight plans in a scenario. It managed the trajectory of each simulated flight and collected and displayed aircraft state 
information for aircraft connected in from other simulations (i.e., the ASTOR aircraft). The interface to the flight 
manager was provided by a plan view of the simulation environment as seen in Figure 3. The position of each aircraft 
in the simulation was shown within the selected zoom window. Also depicted was the trajectory for each aircraft 
(blue lines), any active weather hazard regions (yellow polygons), and the Center airspace boundaries (light grey 
lines). This plan view also provided the menu bar for controlling the simulation environment (top of Figure 3) as well 
as the controls for simulation time and speed (bottom of Figure 3). 
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Figure 3. TBO-TIGAR plan view display with example DRNAV (green) and DRNP (magenta) re-routes. 
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The flights simulated by TBO-TIGAR used a low-fidelity trajectory model. A kinematic trajectory comprised of 
constant speed or constant acceleration legs was generated for each flight using a simple vertical and speed profile. 
The vertical flight profile emulated a single, constant vertical climb rate to a cruise altitude and a single, constant 
vertical descent rate, while the speed profile assumed 250 knots below 10,000 feet and a fixed cruise groundspeed 
above 10,000 feet. Each flight’s initial trajectory was generated from a scenario file to follow a flight plan defined by 
a set of navigational aids, navigational fixes, and/or instrument departure and arrival procedures. 

The TBO-TIGAR tool had the ability to emulate all of the TBO Prototype functions for any flight and an equipage 
field was used to differentiate between fully- and lesser-equipped flights. The two designations for equipage were 
TBO-equipped and non-TBO-equipped to distinguish between aircraft equipped with DataComm and those not so 
equipped, respectively. The non-TBO-equipped flights were assumed to have: voice communications (emulated via 
messaging in the TBO-TIGAR tool); single RTA capability; RNAV; and a conventional FMS capability with lateral 
and vertical guidance modes. The TBO-equipped flights were assumed to have all of these capabilities plus: 
DataComm with CPDLC and ADS-C capabilities; ability to execute dynamic re-routes to include latitude/longitude 
defined waypoints (emulated DRNP without enforcing the RNP conformance); and an advanced FMS capability. This 
advanced FMS capability provided the ability to generate EPP information from the reference trajectory, to auto-load 
DataComm clearance messages, and to load and execute A-IM functions. 

The plan view provided by the flight manager allowed for other user interactions and for the display of specific 
re-route information. A user could utilize a mouse to select any aircraft on the plan view; that aircraft’s trajectory 
color would be shown in red. By right-clicking a mouse on the plan view, the user could select from a list of available 
functions such as: show information about a nearby navigational aid or fix; display the location of the five closest 
navigational aids or fixes; control the drawing of a DRNAV re-route; among others functions. Once initiated, the 
drawing of DRNAV re-routes was a simple drag-and-drop operation on the plan view. The plan view also depicted 
the DRNP re-routes that were generated by the DRNP re-route generation tool. Examples of DRNAV (green) and 
DRNP (magenta) re-routes are shown in Figure 3. 


ATC Automation 

The ATC automation component of TBO-TIGAR provided information about the status of each flight in the 
simulation and allowed for clearance messages to be generated and sent to each flight. An ATC user interface showed 
the flight plan information for each flight (top of Figure 4). Within this ATC view, CPDLC messages with revised 
clearances or instructions could be generated and sent to a constraint action queue for review before being issued to 
the appropriate flight (middle of Figure 4). These instructions included DRNP and DRNAV re-routes, RTA 
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Figure 4. ATC communication hub with flight plan list, trajectory constraint queue, and message log. 
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assignments, and ADS-C requests for EPP information. Shortcut buttons were available to aid in the building of these 
instructions or clearances. The “RNAV -> CPDLC” button auto-populated a clearance message string from an 
available DRNAV re-route. The “Connect to D-RNAV” button checked the feasibility of amending an existing flight 
plan with a DRNAV re-route when the first and last waypoints in the re-route were not already part of that flight plan. 
The “Check If RNAV Clear Of WX” button evaluated whether a flight entering an available DRNAV re-route at a 
specified time and with a specified groundspeed would be in conflict with any weather cell. The “Find WX Status 
All” button compared each flight’s trajectory against the active weather cells to identify any weather conflicts, their 
expected time of occurrence, and whether these flights were candidates for any existing DRNP re-routes, as depicted 
in Figure 5. Finally, the “IM Tool” button provided a utility for generating an A-IM clearance based on a small set of 
input parameters, as seen in Figure 6. All clearances and instructions sent to each flight, including their respective 
responses, were available in the message log (bottom of Figure 4) in the ATC view. 


| le Inter Spacing Clearance Tool Se 
Ti to LoS Ti f L CallS PolyG Candidat E 
a ideal nent ane a Interval Spacing Clearance Parameters 


[04:31:00] UAL1228 wxpoly10 
[04:32:00] AWE689 wxpoly10 YES 
[04:34:40] UAL1539 wxpoly10 YES - Not Equipped 


Target Aircraft: 
Achieve By Point: 
[04:36:40] UAL442 wxpoly10 YES - Not Equipped ae - 
[04:37:10] DAL322 wxpoly10 YES - Not Equipped Termination Polat: 
05:03:40) UAL812 wxpoly10 NO 


Spacing Interval (seconds): 


Create 


Refresh Close 


Figure 5. List of weather conflicts for active flights. Figure 6. Interval spacing clearance 
generation utility. 


The ATC automation also 
provided a dedicated window 


Sim Time: 14034.50[s] [03:53:54] 


for the display of detailed flight J 
. : - Plan Aircraft: |UAL1228 | Index: 1224s 
information. For any flight ; 
: Start Time: 1510.0 [s] End Time: 18832.9 [s} 
selected from the ATC view or we : 
7 A Origin Airport: KSAN Dest. Airport: KEWR 

from the flight manager’s plan a : 

* > 5 _ Position: 41.746°N, 86.542°W, 35000.000 [ft] Velocity: 82.058 [deg], 459.000 [knot], 0.000 [fpm] 
view, a flight information - ’ 

. Pai. " Status: Active, Plan A/C, **Wx Conflict** Equipage: TBO:RTA:IM 
window similar to that in Flight Plan: KSAN.JETTILOWMA.PGY.BROWS.JLI.TRM.EED.TBC.PWE.JOT.GIJ.BENJO.CRL.KEEHO.HUDUG.DORET.ZORBO.B Fe] \ 
Figure 7 was displayed. The Haht Plan: )RiAR.SLT.FOM.HAYED.RACKI.SWEET.KEWR | 
flight information window Saar eg TBC.PWE.JOT.GIJ.BENJO.CRL.KEEHO.HUDUG.DORET.ZORBO.B I 


provided an engineering view 
of each aircraft’s state, its flight 
plan information, as well any 


EPP information available for PP Message: |” “__P:16,N40548617W075136666,1201,,4116.K354,000100000. 
that flight Bath a textual P:17,N40544671W075122678, 1179,,.4129,K250,001000000..,... 


' x : P:18,N40496963W074554592.849.SWEET.4325,K250.,20..1000000.., 
version of the EPP information ..--P:19,N40415500W074101200,2, KEWR,4833,K250,,..1100000,,. = i 
as well as a_ graphical ¥ 
representation of the lateral and 31171 


vertical profiles were available 27507 
é 23843 


in the flight information Baia 
window for TBO-equipped |*°° OS ele 16514 
flights. The lateral and vertical ee 
profile views within the flight 5521 
information window were also 867 | 
used to display re-route 
requests that were received 
from flights in the form of a 
4DT. 


----P:12,N41086350W076032072.2516,HAYED.3766.K459, ...1100000... 


120 21 29 37 #46 54 


Show EPP Show User Pref. Route || Check User Pref. Clear Wx | Dump ExecPlan | 


—} 4d 


Figure 7. Flight information window. 


Traffic Flow Management Automation 
The prototype traffic flow management automation tools provided the functionality typically available to a traffic 
flow manager. This grouping of functions to the traffic manager operational position is somewhat loose because one 
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of the objectives of this focus group activity was to ask participants their 
recommended function allocation. The prototype functions included a 
time-based metering scheduler capability and a dynamic re-route 
generation capability. 

The time-based scheduler capability allowed for metering of traffic 
at a single point or a group of points in space. An example of the time- 
based scheduler can be seen in the timeline of Figure 8. This particular 
scheduler was configured to meter traffic at the group of points 
DMACK, ETG, and SLT as a single meter boundary for traffic destined 
to the New York area airports. The scheduler began computing STAs 
for each flight at a planning horizon 35 minutes prior to the meter points 
and STAs were fixed once each flight passed a freeze horizon 30 minutes 
prior to the meter points. The left side of this timeline view shows the 
ETA for each flight, where the blue “4d” identifier indicates those ETAs 
generated using EPP information provided by those flights. The right 
side of the timeline view shows the STA for each flight as well as the 
amount of delay absorption required to meet that STA (i.e., “AWE689 
1” indicates approximately one minute of delay required). At the bottom 
of the timeline view, a user could input the call sign for any flight in the 
scheduler to view the scheduled time and a button allowed that STA to 
be sent to ATC automation as a proposed RTA constraint for that flight. 

The dynamic re-route capability in TBO-TIGAR allowed for the 
generation of weather-clear re-routes. The interface for this capability 
can be seen in Figure 9. By providing a small number of parameters 
specifying the start, end, starting time, duration, and average 
groundspeed for a desired re-route, the tool would identify an efficient 
re-route around any existing weather constraints. The tool would also 
provide a list of candidate flights based on the flight plans of all active 


CallSign Scheduled Time 


_UAL1228 | 04:45:42 Issue RTA 
Ripple Schedule 


Enable Speed Advisories Max Time: 


Figure 8. Example time-based 
scheduler timeline view. 


flights and the feasibility of the re-route solution for those flights. The re-route solutions included latitude and 
longitude defined waypoints and were assigned turn geometries and leg-specific RNP values to fully specify DRNP 


re-routes. 


. 
[4] Dynamic RNP Window a (o/h al 


Waypoint 1 ISPA Waypoint 2|GSO Clear DNRP Save DNRP | Load DNRP 


L 


Start Time 11300.0 _ Time Window 


Speed [460 0 i | Reroute Wx ReCheck Wx | Send Reroute ATC | Delete From List | 


Find WPs Selected | Connect To DNRP Advanced Parameters | 


ReRoute Num StartTime Window 


11300.0 1200.0 460.0 SPA....N352515W0814973..N354515W0811973..GSO 


Trajectory 


ReachTime CallSign 
DAL1200 dynamic reroute (NOT TBO-EQUIPED) 
DAL1895 dynamic reroute 
DAL2125 dynamic reroute (NOT TBO-EQUIPED) 
DAL843 dynamic reroute 
DAL1041 dynamic reroute (NOT TBO-EQUIPED) 


Figure 9. Weather-clear dynamic re-route generation tool showing the input parameters (top), re-route 
solution (middle), and candidate flights list (bottom). 
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B. Airborne Automation 

The aircraft automation systems used in the 4DT Prototype leveraged the ATOS simulation, which included the 
ASTOR aircraft and its sub-systems. The ASTOR aircraft could receive and provide responses to DataComm 
messages from the ground automation as well as send 4DT information to the ground automation. The UPRR 
generation application, TAP, was used to generate UPRR solutions that could be communicated to ATC for approval. 
The changes that were made to the ATOS simulation more closely mimicked the expected implementation in an 
operational system because those changes primarily involved displaying DataComm messages that have already been 
defined in standards documents. 


ASTOR Aircraft 

The airborne TBO Prototype functionality was implemented within the ASTOR high-fidelity simulation, which is 
part of ATOS. An ASTOR station is a medium fidelity aircraft and avionics simulation with low fidelity single-pilot 
interfaces. An ASTOR contains a high-fidelity six degrees-of-freedom equations of motion aircraft model, autopilot 
and auto-throttle systems, software flight management computer, multifunction control display unit, model control 
panel, and electronic flight instrumentation system control panel as can be seen in Figure 10. The data 
communications system and the RPFMS within the ATOS were modified to handle inbound DRNP re-route messages, 
A-IM messages, and outbound ADS-C reports containing the EPP 4DT, as well as a 4DT representation of a UPRR 
request. The ATOS already had the ability to receive RTA messages. For this activity, one ASTOR station was 
utilized. The majority of the user interaction with ASTOR involved the DataComm message page for reviewing, auto- 
loading, and accepting or rejecting clearance messages, and the RPFMS functions which could be accessed through 
the Control Display Unit (CDU). 


Figure 10. ASTOR simulation with the RPFMS CDU shown at the center of the image. 


Traffic Aware Planner 

In an effort to achieve near-term benefits of ADS-B, NASA developed a Traffic Aware Strategic Aircrew Requests 
(TASAR) concept to enable user-optimal in-flight trajectory re-planning to increase the likelihood of ATC approval 
of re-planning requests. TAP, as can be seen in Figure 11, is the onboard software application that enables the TASAR 
concept. TAP processes surveillance data and other data from onboard sensors, databases, or data links to provide the 
flight crew with information to use to decide whether to make a trajectory change request and what request to make. 
This information can include conflict free trajectory changes recommended by TAP, conflict analysis of pilot entered 
trajectory changes, time and fuel savings, and other attributes. Current procedures are then used to issue and approve 
change requests through voice communication?. 

TAP was loosely integrated with the TBO Prototype as a method for generating UPRRs to demonstrate the early 
stages of trajectory negotiation. In this implementation, the re-route solution provided by TAP was manually entered 
into the ASTOR’s CDU to create a modified route in the RPFMS. This modified route could then be sent to the 
ground automation for review using the data link communications in the ASTOR simulation. Because the modified 
route was available within the RPFMS, the UPRR request was sent to the ground automation using the same 4DT 
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format as an EPP message. 
The air traffic controller was FL390 _ ECON 

able to review the re-route 
request and provide a 
CPDLC message approving 
or disapproving the request. 


Lateral 


Vertical 


C. Communications 

The communication 
between the ground 
automation tools and the 
aircraft automation followed Message 
the Baseline 2 Air Traffic 
Services DataComm Objective 
standards for message types 
and content. Although this 
communication system was 
simulated, each CPDLC or Max WPTS 
ADS-C message contained 
the data elements as ATC Approved ATC Denied Dispatch Winds FL 390 
specified in the published 
standards. Figure 11. TAP route optimizing application. 


Limit 


ALT Limit 


V. Test Method 


SMEs participated in discussions of an Advanced 4DT operational concept that consisted of: a concept overview 
presentation, an interactive demonstration of the TBO Prototype via four scenarios, and a discussion session. The 
purpose of this activity was to obtain feedback on the operational concept that could be used in future concept and 
research development. 


A. Participants 

The participating SMEs for this research activity included five commercial airline pilots and five retired en route 
air traffic controllers. The pilots had an average of over 14,000 flight hours with 36 years of flying experience. The 
en route controllers had an average of over 25 years of experience as active controllers. 


B. Procedure 

Each day of the Focus Group Evaluation included SME input from a pair of participants — one pilot and one 
controller. The SMEs were first given a one-hour briefing that described the Advanced 4DT concept, Prototype, and 
demonstration scenarios. Next, they were guided by researchers through the execution of four scenarios, each taking 
approximately fifteen minutes to complete. The participants filled out a short questionnaire relevant to their 
operational position — pilot or controller — after the completion of each scenario. Finally, the SMEs participated in a 
discussion session for approximately two hours where they provided their input, recommendations, or observations 
with respect to a pre-determined set of operational, technological, and procedural questions (Appendix) regarding the 
concept and the functionality that had been demonstrated during the scenarios. The participants provided input on 
these questions as well as other ad-hoc questions generated during the discussion. Participant comments were 
documented via audio recordings during both the scenario demonstrations and discussion session. 

In the demonstration scenarios, the controller SMEs were sometimes asked to conduct functions that would 
typically be considered inherently traffic flow management functions. The controllers were asked to provide their 
feedback about the allocation of these functions in an Advanced 4DT operational environment. 


C. Demonstration Scenarios 

Four operational scenarios were demonstrated to each pair of SME participants. The scenarios demonstrated 
proposed functionality of the Advanced 4DT concept that could be available in an en route operational environment. 
The participants were guided in executing the objectives of each operational scenario using step-by-step instructions. 
The first three demonstration scenarios illustrated three stages of the same traffic flow through Cleveland Center 
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(Figure 12). These scenarios included seven aircraft equipped as shown in Table 1. The fourth scenario focused on a 
traffic flow through Atlanta Center (Figure 13) and 

included a mixture of TBO-equipped and non-TBO- Table 1. Aircraft equipage for scenarios 1, 2, and 3. 
equipped aircraft. In each scenario, one of the traffic 
aircraft was an ASTOR with a RPFMS andaTAP route Aircraft DRNP / A-IM TAP RTA 
optimization tool that was operated by the pilot DataComm 

participant. The remaining aircraft were lower fidelity 
aircraft simulated within the TBO-TIGAR prototype tool 
and were managed by the controller participant. In all 
scenarios, aircraft equipped with DataComm were 
sharing 4DT information with the ground automation 
tools on a periodic basis (updated 4DT information was 
available every five minutes). 


v 
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SN NA 

M 
7 <i iy Si 
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Ke, [issue in 
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Figure 13. Scenario 4 area of interest. 
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Scenario 1 — Weather-Clear Dynamic Re-Routing 
Scenario 1 demonstrated 
the ability to generate dynamic aren Oren 
re-routes to solve a weather 
conflict with a stream of 
aircraft (Figure 14). Weather 
blocked one of the airways 
through Cleveland Center and . 
ground automation tools were / 
used to generate DRNP and == DRNP re-route \ ; 
DRNAV re-routes to solve the == DRNAV re-routes \ 
weather conflict just prior to FCA 
entering a flow-constrained 
area (FCA) boundary intoNew Figure 14. Weather-clear dynamic re-routing of scenario 1 (DRNP — magenta, 
York Center. The re-routes DRNAV - cyan). 
were issued to each aircraft 
based on their equipage. The 
ASTOR aircraft received a DRNP re-route request via data link as well as an ADS-C request for 4DT information. 
The weather-clear dynamic routes that were generated in this scenario resulted in conflicts with other traffic streams, 
thereby requiring additional dynamic re-routing for those flights. DRNAYV re-routes we generated for non-TBO- 
equipped aircraft. All re-routes were designed to re-connect at the downstream meter points of DMACK and SLT. 


Scenario 2 - Aircraft Specific Re-Routing and Electronic Negotiation 

Scenario 2 demonstrated 
early stages of trajectory 
negotiation in a TBO 
environment (Figure 15). The 
ASTOR aircraft (aircraft 1 in 
Figure 15) had the ability to 


NOTE: not to scale 


generate UPRR requests, using . 

the TAP application, and to ! 
send those requests to ground -= DRNP re-route @ a. 
automation via DataComm. Sieadntdsiai lib chicka \ 
One such UPRR, as shown in on User pe ioe FCA 
Figure 15, was generated and 

sent by the pilot to the ground Figure 15. User-initiated re-route request (green) of scenario 2. 
automation where the 


controller participant was able to review the request and accept it via a DataComm clearance. 


Scenario 3 — Flow Management 

Scenario 3 demonstrated 
the ability to apply different 
control strategies in meeting a 
metering schedule (Figure 16). 
A time-based scheduler 
provided scheduled times of 
arrival for aircraft crossing 
from Cleveland Center into 


NOTE: not to scale 


New York Center. The DRNP re-route 
controller participant used the DRNAV re-routes 
ground automation tools to User-pref. route 
generate RTAs and A-IM RTA 
clearances that were sent to 


aircraft. after passing the Figure 16. Time-based metering control of scenario 3. 
scheduler’s freeze horizon. 
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TBO-equipped flights received either an RTA clearance (aircraft | and 2 in Figure 16) or an A-IM clearance (aircraft 
3 in Figure 16) via DataComm. Non-TBO-equipped flights received an RTA voice clearance (aircraft 5 in Figure 16) 
or a speed instruction (aircraft 4 in Figure 16). 


Scenario 4 — Dynamic Re-Routing, On-Demand Metering, and Flow Management 
Scenario 4 demonstrated a 
somewhat different approach to the NOTE: not fo scale 
same capabilities of scenarios | and 
3 and added the ability to generate 
an on-demand, time-based 
scheduler for flow control through 
the dynamically-generated _ re- 
routes (Figure 17). In this scenario, 
weather blocked a busy airway 
through Atlanta Center. The 
ground automation was used to 
identify the aircraft that were 
projected to be impacted by the 
weather and to generate DRNP and 
DRNAV re-routes that leveraged a 
gap in that weather. These re-route 
solutions did not start or end on the 
impacted airway. The ground 
automation was used to evaluate 
the feasibility of the re-routes for Figure 17. Dynamic re-routes and on-demand metering of scenario 4. 
each of the weather-conflicted 
flights based on the aircraft’s equipage and the geometric feasibility of the proposed flight plan amendment; re-routes 
were assigned to each flight based on equipage. An on-demand metering scheduler was created to manage the flow 
at the exit to the dynamic re-routes and was used to implement schedule control strategies such as RTA and A-IM 
clearances. 


On-demand 
Metering Boundary 


== DRNP re-route 
== DRNAV re-route 


VI. Results 


The SMEs participated in the interactive demonstrations and provided feedback in the form of brief post-scenario 
questionnaires as well as researcher-guided debrief discussion sessions where the participants discussed their 
impressions and recommendations. The results from these post-scenario activities are presented in the following 
sections. 


A. Scenario Qualitative Results 

At the end of each scenario, the SMEs completed a post-scenario questionnaire. The post-scenario questions were 
presented as statements and the SMEs were asked to rate their agreement with those statements on a scale of | (strongly 
disagree) to 7 (strongly agree). The controller and pilot SMEs provided ratings to statements regarding each of their 
respective domains, i.e., with respect to ground-based traffic control and management for controllers and with respect 
to flight deck operations for the pilot. This section provides the SME questionnaire ratings. 


Controller Post-Scenario Questionnaire Results 

The mean ratings for the post-scenario questions for the five controller SMEs are presented in Table 2. The number 
of responses for each question and rating are shown in Figure 18 through Figure 23. All controllers agreed or strongly 
agreed that they fully understood what was going on during the scenario (Question A) (Figure 18). All of the 
controllers agreed or strongly agreed that it was easy to understand what was going on during the scenario in terms of 
mental effort required (Question B) (Figure 19). All controllers agreed or strongly agreed that they would use the 
operational capability encountered in the scenario to re-route aircraft (Question C) (Figure 20). All controllers, except 
for one, did not feel that the operational capabilities encountered would hinder their duties (Question D). One 
controller slightly agreed that the operation capabilities encountered during all scenarios would hinder his duties 
(Figure 21). All controllers agreed that they could use the operational capabilities encountered to manage traffic and 
still maintain situation awareness (Question E) (Figure 22). All controllers, except for one, agreed or strongly agreed 
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that they could use the operational capabilities encountered to manage traffic and maintain low mental workload 
(Question F). One controller was neutral in rating the ability to use the operational capabilities encountered in Scenario 
3 to manage traffic and maintain low mental workload (Figure 23). 


Table 2. Controller post-scenario questionnaire ratings. 


Question Scenario 1 Scenario2 Scenario3 Scenario 4 
(u, 6) (u, 6) (u, 6) (u, 6) 

A. I fully understood what was going on during this 6.4, 0.5 6.6, 0.5 6.6, 0.5 6.6, 0.5 
scenario. 

B. It was easy to understand what was going on during 6.6, 0.5 6.6, 0.5 6.6, 0.5 6.6, 0.5 
this scenario (in terms of mental effort required). 

C. I would use this operational capability (DRNP, 6.8, 0.4 6.8, 0.4 6.6, 0.5 6.6, 0.5 
DRNAV, UPRR, RTA, A-IM) to re-route aircraft. 

D. This operational capability would hinder my duties. 2.6, 1.5 2.4, 1.5 2.4, 1.5 2.6, 1.5 


E. Icould use this operational capability to manage traffic 6.6, 0.5 6.6, 0.5 6.2, 0.8 6.4, 0.5 
and still maintain my situation awareness. 


F. I could use this operational capability to manage traffic 6.2, 0.4 6.4, 0.5 6.2, 1.3 6.4, 0.5 
and maintain low mental workload. 


fi = mean, o = standard deviation 


A. | fully understood what was B. It was easy to understand what was going on during 
6 going on during this scenario. 6- this scenario (in terms of mental effort required). 
Hil Scenario 1 Wl scenario 1 
5 | |llScenario 2 5 + [lllsScenario 2 
3 Hil scenario 3 3 Mi scenario 3 
Eat Hil Scenario 4 Sab Hil scenario 4 
[oe a 
3 3 
aw 3h a 3b 
6 xe) 
® ® 
a b a L 
E = Ee . 
3 5 
Zz Zz, 
1; 17 
a. 2 @ ae Bee i 2. 3 4 & & 7 
Strongl 4 Strongl 
siongly Rating Strongly : ay Rating gly 
Disagree Agree Disagree Agree 
Figure 18. Controller responses for post-run Figure 19. Controller responses for post-run 
question A. question B. 


Additionally, controllers were asked which controller position(s) should handle the operational capabilities 
encountered during each scenario (Question G). In general, the controllers felt that the traffic management unit (TMU) 
or traffic management coordinator (TMC) should be responsible for generating the operational constraints 
demonstrated by each of the scenarios (dynamic re-routes, UPRR initial approval, time constraints, spacing 
constraints), particularly when the traffic load is heavy, while ATC should be responsible for the implementation of 
those constraints. Some controllers felt that the D-side controller, or data controller, could also be responsible but the 
R-side controller, or radar controller, should only handle traffic re-routes if the traffic loads were normal. The R-side 
controller uses radar information as the primary method for separating aircraft and is in direct communication with 
the aircraft. The D-side controller is the assistant to the R-side controller and is responsible for sequencing flight 
strips, providing non-radar separation under certain circumstances, and assisting the R-side controller with 
coordination with other sectors. 
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C. | would use this operational capability (D-RNP, D-RNAV, 
user-preferred route, RTA, A-IM) to reroute aircraft. 


Hil scenario 1 
5 | |llScenario 2 
HS Scenario 3 
at Hi scenario 4 


Number of Responses 
w 


Wg eee ge ee ee 


2 3 4 5 6 7 
Strongly ‘ Strongly 
Disagree Rating Agree 


Figure 20. Controller responses for post-run 
question C. 


E. | could use this operational capability to manage 
traffic and still maintain my situation awareness. 
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Figure 22. Controller responses for post-run 
question E. 


D. This operational capability 
would hinder my duties. 
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Figure 21. Controller responses for post-run 
question D. 


F. | could use this operational capability to 
manage traffic and maintain low mental workload. 
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Figure 23. Controller responses for post-run 
question F. 


Pilot Post-Scenario Questionnaire Results 

The mean ratings for the post-scenario questions for the five pilot SMEs are presented in Table 3. The number of 
responses for each question and rating are shown in Figure 24 through Figure 29. All pilots, except for one, agreed 
or strongly agreed that all the operational capabilities encountered would be useful to them for performing TBO 
(Question A). One pilot was neutral in rating the RTA capability as being useful for performing TBO (Figure 24). 
All of the pilots did not feel that the operational capabilities encountered would hinder their duties (Question B) 
(Figure 25). All pilots agreed that they could perform the operations encountered and still maintain situation 
awareness (Question C) (Figure 26), maintain low mental workload (Question D) (Figure 27), and maintain low 
physical workload (Question E) (Figure 28). The pilots also agreed that the user interface was effective for performing 
the operation encountered (DRNP, UPRR, and RTA) (Question F) (Figure 29). 


17 


American Institute of Aeronautics and Astronautics 


Number of Responses 


Figure 24. Pilot responses for post-run question A. 


Number of Responses 


A. This operational capability will be useful 
to me for performing trajectory-based operations. 


Hil Scenario 1 
| | Scenario 2 

Hl Scenario 3 
| |Hliscenario 4 

— a ee 
Strongly : Strongly 
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C. | could perform this operation (D-RNP, user-preferred 
route, RTA) and maintain my situation awareness. 


Hil scenario 1 
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Figure 25. Pilot responses for post-run question B. 
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would hinder my duties. 
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D. | could perform this operation 
while maintaining low mental workload. 
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Figure 26. Pilot responses for post-run question C. Figure 27. Pilot responses for post-run question D. 


E. | could perform this operation 
while maintaining low physical workload. 


F. The user interface was effective for performing 
this operation (D-RNP, user-preferred route, RTA). 
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Figure 28. Pilot responses for post-run question E. Figure 29. Pilot responses for post-run question F. 
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Table 3. Pilot post-scenario questionnaire ratings. 


Question Scenario 1 Scenario 2 Scenario3 Scenario 4 
(u, 6) (u, 6) (u, 6) (u, 6) 
A. This operational capability will be useful to me for 6.4, 0.5 6.0, 0.0 6.0, 1.2 6.0, 0.0 
performing trajectory-based operations. 
B. This operational capability would hinder my duties. 2.0, 0.7 2.2, 0.4 1.8, 0.4 2.0, 0.0 


C. Icould perform this operations (DRNP, UPRR, RTA) 6.4, 0.5 5.8, 0.4 6.4, 0.5 6.0, 0.0 
and maintain my situation awareness. 


D. Icould perform this operation while maintaining low 6.4, 0.5 5.6, 0.5 6.0, 0.7 6.0, 0.0 
mental workload. 
E. Icould perform this operation while maintaining low 6.6, 0.5 5.8, 0.8 6.4, 0.5 6.4, 0.5 
physical workload. 
F. The user interface was effective for performing this 6.4, 0.5 6.2, 0.4 6.2, 0.4 6.2, 0.8 
operation (DRNP, UPRR, RTA). 
fi = mean, o = standard deviation 


B. Post-Scenario Discussion Session and Findings 

After participating in the interactive scenarios, the SMEs participated in a researcher-guided debrief and discussion 
session where they provided their input, recommendations, or observations with respect to a pre-determined set of 
operational, technological, and procedural questions regarding the concept and the functionality that had been 
demonstrated during the scenarios. Audio recordings were gathered and transcribed for each discussion session. A 
summary of the most relevant input is presented in this section. 

The controller SMEs felt that it was easy to understand what was happening during each scenario and that they 
would use the operational capabilities demonstrated (DRNP, DRNAV, UPRR, RTA, A-IM) to re-route aircraft. They 
also felt that the operational capabilities demonstrated would not hinder their duties and could be used to manage 
traffic while maintaining situation awareness and low mental workload. The pilot SMEs felt that the operational 
capabilities demonstrated (DRNP, UPRR, and RTA) would be useful for performing TBO and would not hinder their 
duties. They also felt that they could perform the operations encountered and still maintain situation awareness, low 
mental workload, and low physical workload. 

In today’s air traffic system, the tactical management of aircraft around weather is done using controller-issued 
vectors or clearances that allow for deviation from the current flight plan within some predefined limits. With 
vectoring, the controller issues heading instructions as necessary to steer the aircraft through a weather region while 
maintaining safe separation from nearby traffic. This has the side-effect that the pilot does not know when the 
controller will turn the aircraft back to rejoin their original route. Conversely, when the aircraft is provided with a 
deviation clearance, the controller will not have any way to know the exact route the aircraft will follow through the 
weather and needs to maintain a significant region of airspace clear for the deviating aircraft. The SMEs felt the TBO 
concept demonstrated produced defined routings around the weather which resulted in a more organized, consistent 
flow of traffic where it was clear to both the controller and pilot what route the aircraft was to follow. This would 
give the controller more confidence in re-routing the traffic closer together because the exact route would be known. 
The controller SMEs indicated that better equipage typically translates to more effective re-routing and less vectoring. 
It is important to be able to re-route all aircraft in the same direction around weather; however, opposite direction 
traffic must be taken into consideration to avoid conflicts. When re-routing is required and re-routing plans are 
developed, the aircraft should be notified as soon as possible to allow time to prepare. 

One common theme throughout the activity was that, in general, the controller SMEs felt the TMU or TMC should 
be responsible for generating and negotiating the operational constraints demonstrated (dynamic re-routes, UPRR 
initial approval, time constraints, and spacing constraints) in cooperation with the Command Center, while ATC 
should be responsible for the implementation of those constraints. This function allocation is applicable particularly 
when the traffic load is heavy or the re-route involves more than one sector. Some controllers felt that the data 
controller could also be responsible for re-route planning but that the radar controller should only handle re-route 
planning if the traffic loads were normal, or for pop-up weather events. However, the controllers did feel that they 
should be consulted when the re-routes are developed, particularly when the re-route affects their sector, because they 
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have more information on the conditions in the immediate area and better insight on the effects of the route changes. 
The SMEs noted that trajectory negotiation and changes could also be done by automation as long as humans set the 
negotiation parameters and have the ability to intervene when conditions change. 

The pilot SMEs indicated that there would be plenty of time to re-plan a route from the flight deck during en route 
operations. Dispatch would not have any issues with the pilot re-planning the route and would not impose constraints 
limiting the number of re-routes. Some pilots felt they were obligated to inform the dispatcher of the re-route and 
some stated that dispatch must be notified when the route caused deviations of 100 nautical miles or more. Many 
factors determine when it is beneficial to request a UPRR, such as passenger’s connecting flights, amount of fuel 
onboard, and time and fuel savings. Pilot SME opinion varied on the minimum amount of time and fuel savings 
required to justify the request for a UPRR; from one to five minutes time savings and 100 to 500 pounds of fuel 
savings. When using automation onboard the aircraft to generate UPRR options, the pilot SMEs indicated that they 
would only want two or three options to select from. Having more than one option available aids in the negotiation 
process. The controller SMEs indicated they would trust using an airborne generated trajectory; however, they would 
verify the trajectory and monitor conformance. 

Both the controller and pilot SMEs felt that DataComm would be very beneficial for TBO operations. DataComm 
would result in less workload due to reduced communications, would eliminate issues due to language barriers and 
frequency problems, and would make receiving, loading, accepting, and executing clearances easier, less ambiguous, 
and more expeditious. However, it was noted that pilots may not be able to anticipate situations, such as re-routes and 
turbulence, when they are unable to hear other aircraft communications. Procedures for loading and accepting data 
link messages must also be properly defined. 

Other automation and technology the controller SMEs felt would be needed to successfully conduct TBO 
operations included the ability to display where the re-route will reconnect to the active route, the ability to create a 
re-route for a stream of aircraft, a conflict probe applied to the UPRR prior to sending to the controller, an indication 
that a UPRR has been received by the ground automation, a method of displaying aircraft equipage level to show each 
aircraft’s TBO and data link capabilities, and the ability to view the active route for multiple aircraft. Although a few 
controller SMEs indicated it would be beneficial to view the current flight plan as well as the planned route along with 
turn geometry, most felt that viewing the 4DT of each aircraft, especially the vertical profile, is too much information 
for a controller. Suggestions were also given for the ground-based and flight deck user interface, such as an RTA 
status indication showing the time early or late in meeting that RTA. The pilot SMEs were also concerned with the 
current implementation for sending a UPRR request for approval which resulted in an open execute light. It is not 
good practice to leave an open execute for an extended period of time but the pilots did understand that the prototype 
implementation of this capability was not intended to mimic a proposed operational procedure but, rather, a proposed 
functionality that needs an operational procedure definition. 

The SMEs also noted other benefits of the TBO functionality demonstrated. These benefits include improved 
traffic flow, fuel and time savings, and decreased workload. The TBO functionality that would provide the most 
benefit with the least equipage was identified as RTAs, dynamic re-routes that are defined with latitudes and 
longitudes, the ability to receive UPRR requests via DataComm, and the ability to view re-route options onboard the 
aircraft. 

The SMEs identified some challenges in implementing a TBO concept. These included education (i.e., training 
and change in mindset), consistent operations in a mixed equipage environment where all aircraft do not have the 
same capabilities/functionality, FAA implementation of new TBO equipment, and purchase of the necessary 
equipment by the airlines. 


VII. Conclusions 


An Advanced 4DT concept will integrate existing and proposed TBO technologies, as well as incorporate new 
technology where needed, to create automation tools and procedures that support gate-to-gate TBO. NASA developed 
an Advanced TBO Prototype simulation toolkit that demonstrated some of the functionality that could be part of an 
Advanced 4DT TBO concept. The objectives of the Prototype were to develop an initial TBO simulation capability 
leveraging existing tools where possible and rapid prototypes as needed; develop an initial set of requirements for 
ground and airborne systems for performing TBO operations; and engage stakeholders and SMEs in the development 
and refinement of the concept. Controller and pilot SMEs participated in discussions on an Advanced 4DT operational 
concept and were provided an interactive demonstration of the TBO Prototype using four example scenarios. The 
SMEs provided feedback on potential operational, technological, and procedural opportunities and concerns. 
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Overall, the SMEs felt that the Advanced TBO concept presented and Prototype demonstrated had the potential 
for improving en route operations. Many questions still remain regarding this proposed concept. For example, what 
are the additional coordination requirements between controllers and the TMU when the TMU is primarily responsible 
for generating trajectory constraints (e.g., dynamic re-routes, RTAs) while the controller is primarily responsible for 
issuing clearances and maintaining safe separation? What level of detail is required with a TMU-generated constraint 
to allow controllers to clearly understand the reasoning behind that constraint, prior to issuing a clearance? What tools 
can be made available on the flight deck to support dynamic re-routing for aircraft of different equipage? The feedback 
obtained during this activity will be used to start to answer these and other questions, and to further develop the 
Advanced 4DT concept. 
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Appendix 


A. Operational Questions 


Controller and Pilot 

O1. From your perspective, what are the benefits/impacts of trajectory-based operations (TBO)? 

O2. Will TBO help you in performing your job? Why? 

O03. Do you feel that TBO will increase, decrease, or otherwise change your workload? If so, in what way? 

O04. What challenges do you see in implementing a TBO concept? Please comment on issues such as mixed 
equipage environment, etc. 

O5. Do you prefer segregated airspace in which equipped and unequipped aircraft do not operate together or do 
you believe there is a role for integrated airspace in which equipped and unequipped aircraft operate together? 

O06. Do you have any safety concerns or issues with the TBO concept that was presented to you today? If so, what 
are they? 

O7. How do you think these new TBO procedures should be integrated with current operational procedures? 

O8. What do you think the humans’ role should be in trajectory negotiation and changes? (Note: Does 
management (TMC) setup negotiation strategy and DST prompts controller and pilot?) 

O9. How do you anticipate the airlines will attempt to game the system? Do the airlines do this today? 


Controller 
O10. How would you monitor pilot conformance to RTAs? To IM clearances? 
O11. How much time would you have to evaluate or generate proposed dynamic routes? Under normal conditions? 
Under severe weather conditions? 
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O12. When would you want to be involved in developing dynamic rerouting? What would you want the role of 
the supervisor and traffic management unit to be? 
O13. How would you review a proposed re-route before issuing it to aircraft? What information would you need? 


Pilot 

O14. How much time would you have to devote to re-plan your route when you’re in cruise flight? 

O15. Do you feel that your dispatchers would be supportive of you re-planning the route while en route? 

O16. What constraints may your airline impose to limit the number of re-routes that are generated by the flight 
deck (i.e., need dispatch concurrence for deviations more than 100 nautical miles from the original route)? 

O17. Do you think that these constraints may be relaxed as route re-planning from the flight deck becomes more 
normal? 

O18. When is it beneficial to do user preferred routing? How much time / fuel needs to be saved? 


B. Technological Questions 


Controller and Pilot 
T1. What additional automation/tool capabilities do you think you would need to successfully conduct operations 
that you saw during this demonstration? 
T2. What subset of TBO functionality would produce the greatest benefit with minimal equipage requirements? 


Controller 
T3. Should an air traffic controller have the ability to visualize an aircraft’s planned 4D trajectory? If so, by what 
method — 3D path, separate vertical/horizontal profiles, other? If not, why? 
T4. Would you trust using an airborne generated trajectory for scheduling and sequencing? 
T5. What information will you need to enable you to plan and manage aircraft 4D trajectories? 
T6. Do you have any specific ideas/suggestions for a user interface? 
T7. What level of detail would you like to know about an aircraft’s level of equipage? 


T8. Have you ever conducted an RTA operation? If so, have you used the time component of the 4D trajectory? 
T9. What information will you need to enable you to conform to a 4D trajectory? 
T10. Do you have any specific ideas/suggestions for modifications to the user interface? 


C. Procedural Questions 


Controller and Pilot 
Pl. Assuming multiple route options meet the constraints, how many options would you want to see displayed? 
Would you like the ability to sort based on user-preferred business models? 


Controller 

P2. Based on your experience vectoring aircraft around weather, do weather gaps persist long enough for 
persistent routes to be useful or are individual user-preferred routes required? 

P3. What agent should be the first to review a request for a user-preferred route if sent by data link — air traffic 
controller, traffic management unit, controller decision support tool, other? 

P4. Should an air traffic controller have a role in strategic trajectory negotiation? If not, where should this 
negotiation be done? 

P5. When there are multiple but nearby routes, how would you re-route aircraft in the event of weather if some 
aircraft are RNP equipped and some are not? 

P6. When would you notify aircraft that they need to re-route? 10 nautical miles prior to re-route? 


Pilot 
P7. Should a flight crew have the ability to accept/reject a request for 4D trajectory information (ADS-C / EPP) 
from the air navigation service provider (ATC) or should these requests be automatically granted and executed 
by the FMS? Why? 
P8. Do you see the flight crew as having a role in strategic trajectory negotiation for user preferred routings after 
the aircraft is airborne or should this trajectory negotiation occur between the airline operation center and the 
service provider and the solution uploaded to the flight deck? 


22 


American Institute of Aeronautics and Astronautics 


